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1.0  INTRODUCTION 

This  chapter  explains  the  purpose  of  the  convention,  and  the  scope 
of  the  guidance  and  provides  an  explanation  of  how  to  use  the 
convention. 

1.1  PURPOSE  OF  THE  CONVENTION 

The  convention  provides  general  guidance  on  the  implemenution 
of  American  National  Standards  Institute  (ANSI)  Accredited  Stand¬ 
ards  Committee  (ASC)  XI2  electronic  data  interchange  (EDI) 
standards  within  automated  information  systems  (AIS)  and  on 
information  interchange  procedures  that  require  the  collection, 
reporting,  and/or  exchange  of  data  needed  to  perform  defense 
missions. 

IJ  SCOPE 

The  guidance  presented  here  may  be  used  by  organizational  ele¬ 
ments  of  the  E>oD  community  and  by  non-DoD  organizations  that 
exchange  data  with  the  DoD  community  in  the  course  of  their 
business  relationships. 

The  DoD  community  encompasses  the  Military  Services,  Organiza¬ 
tions  of  the  Joint  Chiefs  of  Staff,  Unified  and  Specified  Commands, 
Office  of  the  Secretary  of  Defense,  and  the  Defense  agencies.  (That 
community  is  collectively  referred  to  as  the  DoD  Components). 

Non-DoD  organizations  include  (a)  non-Govenunent  organiza¬ 
tions,  both  commercial  and  nonprofit;  (b)  Federal  agencies  of  the 
United  States  Government  other  than  DoD;  (c)  local  and  state 
governments;  (d)  foreign  national  governments;  and  (e)  interna¬ 
tional  government  organizations. 

The  draft  convention  published  in  this  document  is  for  trial  use 
and  comment.  DoD  Components  must  submit  to  the  Office  of  the 
Under  Secretary  of  Defense  (Acquisition  and  Technology),  Com¬ 
puter-aided  Acquisition  and  Logistics  Support  and  Electronic  Data 
Interchange  [OUSD  (A  &  T)  CALS/EDI]  their  data  requirements 
that  are  not  covered  in  this  convention  as  soon  as  possible,  as 
indicated  in  Chapter  2.0,  Section  2.1. 

13  RESPONSIBLE  ENTITY 

{Reserved} 

1.4  HOW  TO  USE  THE  IMPLEMENTATION 
CONVENTION 

The  main  topics  and  structures  of  this  document  conform  to  the 
ED/  Implementation  Reference  Manuel  Guidelines  document  that 
was  developed  by  a  task  group  of  the  subcommittee  on  education 
and  implementation  of  the  ASC  XI 2.  The  purpose  of  having 
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agreed-upon  topics  and  structure  is  to  facilitate  reference  by  the 
many  industry  and  DoD  personnel  who  are  involved  in  implement¬ 
ing  the  uniform  standards  for  electronic  interchange  of  business 
transactions. 

1.4.1  Conventions,  Standards,  and  Guidelines 

The  terms  conventions,  standards,  and  guidelines  are  used 
throughout  this  document  and  are  defined  as  follows; 

•  Conventions  are  the  common  practices  and/or  interpretations 
of  the  use  of  ASC  X12  standards.  Conventions  define  what  is 
included  in  a  specific  implementation  of  an  ASC  X12  standard. 

•  Standards  are  the  technical  documentation  approved  by 
ASC  X12:  specifically,  transaction  sets,  segments,  data  ele¬ 
ments.  code  sets,  and  interchange  control  structure.  Standards 
provide  the  structure  for  each  ASC  X12  document. 

•  Guidelines  are  instructions  on  the  use  of  EDI.  They  provide 
additional  information  to  assist  in  conducting  EDI.  Guidelines 
are  intended  to  provide  assistance  and  should  not  be  your  sole 
source  of  information. 

1 .4. 1 . 1  Who  Develops  the  Conventions? 

Conventions  result  from  a  joint  effort  by  business,  technical,  and 
EDI  ASC  Xi2  standards  experts.  The  business  data  requirement 
is  defined,  a  transaction  set  is  selected,  and  the  data  requirement 
is  then  icfentified  with  data  elements  in  the  transaction  set.  A 
convention  is  usually  developed  before  any  computer  EDI  systems 
development  work  and  serves  as  a  design  document  when  the 
development  process  begins. 

1 .4.1  J2  Why  Um  a  Convention? 

To  create  an  ASC  X12  transaction,  a  user  must  know  the  data 
requirements,  understand  the  ASC  XI 2  standard,  and  be  able  to 
use  that  information  to  develop  an  interface  program  between  the 
computer  application  and  the  ASC  X12  translator.  The  necessary 
information  to  perform  that  task  is  contained  in  the  convention 
document.  Users  who  follow  the  convention  will  create  a  transac¬ 
tion  set  that  all  DoD  users  understand. 

1 .4.1 .3  Who  Needs  a  Convention? 

System  analysts  and  application  progranuners  who  plan  to  create 
or  read  ASC  X12  transactions  use  a  convention  to  aid  in  interface 
software  design.  The  convention  will  help  the  programmer  and 
analyst  identify  where  their  application  data  requirement  should  be 
carried  in  an  ASC  X12  transaction  set. 

1 .4.4.4  Can  I  Develop  a  Convention? 

Conventions  already  exist  for  some  of  the  most  common  business 
practices.  Copies  of  existing  conventions  can  be  acquired  through 
your  organization’s  EDI  coordinator  at  the  start  of  an  EDI  project. 
If  you  find  no  conventions  for  the  business  practice  you  are  about 
to  implement,  your  EDI  coordinator  should  contact  the  CALS 
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Evaluation  and  Integration  Office.  See  Chapter  2.0,  Maintenance, 
Section  2.1  for  the  point  of  conuct. 

1.4.2  Documentation  of  Conventions 

Conventions  are  adopted  trom,  and  are  intended  to  be  in  confor¬ 
mance  with,  ANSI  ASC  X12  standards  or  ASC  X12  Draft  Stand¬ 
ards  for  Trial  Use  (DSTU). 

1. 4.2.1  Transaction  Set 

Figure  1.4-1  provides  an  example  of  a  transaction  set  uble.  The 
transaction  set  defines  information  of  business  or  strategic  sig¬ 
nificance  and  consists  of  a  transaction  set  header  segment,  one  or 
more  data  segments  in  a  specified  order,  and  a  transaction  set 
trailer  segment.  The  actual  ASC  X12  standard  as  it  appears  in  the 
official  ASC  X12  standards  manual  is  presented  on  the  right  side 
of  the  page.  That  standard  also  includes  both  syntax  notes  and 
comments.  The  specific  DoD  usage  designator  is  presented  on  the 
left  side  of  the  page. 

The  designation  “N/U"  stands  for  “not  used”  and  appears  in  the 
left  column  if  DoD  does  not  use  the  specific  segment.  A  page 
number  will  appear  if  the  segment  is  used. 

1.4.2J2  Transaction  Sat  Segment 

Figure  1.4-2  is  an  example  of  a  transaction  set  segment. 

DoD  usage  is  specified  on  the  left  side  of  the  page.  For  identifier 
(ID)-type  data  elements,  acceptable  code  values  are  listed  on  the 
right  side  of  the  page  under  the  definitions  of  the  element. 

DoD  notes,  reflecting  how  the  convention  is  to  be  used  appear  on 
the  light  side  of  the  page  at  the  segment  level  or  the  data  element 
level. 

The  following  definitions  are  for  use  in  interpreting  the  data 
element  requirement  designators  in  the  DoD-specific  segment 
directory  section  of  the  convention.  For  ASC  XI2  usage,  see  the 
definitions  in  X12.6  Application  Control  Structure. 

•  Mandatory 

Mandatory  data  elements  ate  defined  by  ASC  X12. 

•  Optional 

C^tional  data  elements  are  used  at  the  discretion  of  the  sending 
party  or  are  based  upon  mutual  agreement  between  trading 
parmers. 

•  Required 

Required  data  elements  are  considered  optional  under 
ASC  X12  rules  but  are  required  by  DoD  decision. 

•  Recommended 

Recommended  data  elements  are  considered  optional  under 
ASC  X12  rules  and  by  the  DoD,  but  the  industry  recommends 
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824  Application  Advice 

This  Standard  provides  ttie  format  and  establishes  the  data  contents  of  the 
Application  Advice  Transaaion  Set  (824)  within  the  context  ot  an  Electronic 
Data  interchange  lEOD  environment  This  transaction  set  provides  the  ability 
to  report  the  results  ot  an  application  system  s  data  content  edits  of 
transaaion  sets  The  resuRs  of  editing  transaaion  sets  can  be  reported  at  the 
tunaional  group  and  transaaion  set  level,  m  eRher  coded  or  tree-form  format 
It  IS  designed  to  accomodate  the  business  need  ot  reporting  the  acceptance, 
reieaion  or  acceptance  wrth  change  of  any  transaaion  sat.  The  Application 
Advice  Should  not  be  used  in  place  of  a  transaaion  set  designed  as  a 
specific  response  to  another  transaaion  set  (e  g.,  purchase  order 
acknowledgement  sent  in  response  to  a  purchase  order). 
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Figure  1.4-1  Example  of  a  Transaction  Set  Table 
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Figure  1 .4-2  Example  of  a  Transaction  Set  Segment 
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their  use  to  facilitate  EDI.  Most  companies  lo  the  industry 
are  expected  to  use  this  data  element. 

•  Not  Used 

"Not  Used"  data  elements  are  those  that  DoD  does  not  use. 

•  Conditional 

Conditional  data  elements  depend  on  the  presence  of  other  data 
elements  in  the  transaction  set. 
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2.0  MAINTENANCE 

This  chapter  describes  the  procedures  for  maintaining  the  DoD 
conventions,  it  also  presents  a  section  on  version/release  tinung. 

2.1  MAINTAINING  CONVENTIONS 

{ Reserved } 

2J  VERSION/RELEASE  TIMING 

Identification  of  the  official  “version”  of  a  standard  is  critical  to 
the  successful  interchange  of  information.  Each  participant  must 
be  able  to  send  and  receive  the  same  version  to  ensure  the  accuracy 
of  the  information  exchanged. 

The  version  is  transmitted  as  a  1 2-character  code  in  the  Functional 
Group  Header  segment  (GS)  in  Data  Element  #480,  Ver¬ 
sion/Release/Industry  ID.  This  12-cbaracter  code  is  used  by 
ASC  X12  as  follows; 

Position  Content 

1-3  Version  number 

4-5  Release  level  of  version 

6  Subrelease 

7-12  DoD/Industry  or  Trade  Association  ID 

ASC  X12  assigns  the  codes  in  Positions  1  through  6. 

The  version  number  (001,  002,  003,  etc.)  will  change  only  after  an 
official  public  review  cycle  leads  to  republication  of  a  new 
American  National  Standard. 

The  release  level  of  each  new  major  version  (Positions  4-6  in  the 
Functional  Group  Header)  will  begin  at  “000”  and  increased  by  1 
for  each  new  ASC  X12  approved  publication  cycle,  usually  once 
a  year.  The  fourth  and  fifth  characters  designate  the  release  and 
the  sixth  character  designates  the  subrelease. 

The  DoD  Industry  Trade  Association  ID  (Position  7-12)  is  used 
to  identify  conventions.  For  this  suffix,  DoD  will  use  “DoD_” 
with  the  10th  character  identifying  successive  publications.  The 
1 1th  and  12tb  characters  may  be  used  by  the  Military  Departments 
or  Defense  agencies. 

DoD  conventions  for  using  ASC  X12  standards  are  published 
annually.  Conventions  developed  for  each  release  will  be  main¬ 
tained  for  4  years.  Military  Services  and  DoD  agencies  will 
determine  which  release  to  use  on  the  basis  of  business  need  but 
will  not  use  any  release  more  than  4  years  old  without  approval 
by  the  OUSD  (A  &  T)  CALS/EDI. 
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3.0  DoD  CONVENTIONS  FOR  USING 
ASC  X12  TRANSACTION  SETS 


This  chapter  defines  the  DoD  transaction  set  conventions.  It 
includes  the  instructions  for  implementing  the  control  structure  and 
definitions  of  the  usage  indicators  and  applicable  codes. 

3.1  INTRODUCTION 

The  power  of  the  ASC  X12  standard  is  in  it"^  building  block 
concept,  which  standardizes  the  essential  elements  of  business 
transactions.  The  concept  is  analogous  to  a  "standard  bill  of 
materiels  and  the  construction  specifications,”  which  gives  the 
architect  flexibility  in  what  can  be  designed  with  standardized 
materiels  and  procedures.  The  EDI  system  designer,  like  the  ar¬ 
chitect,  uses  the  ASC  XI 2  standards  to  build  business  transactions 
that  are  often  difieren*  because  of  their  function  and  yet  utilize  the 
ASC  X12  standards.  The  ‘  bill  of  materiels  and  the  constructiou 
specification”  of  ASC  X12  are  the  standards  found  in  the  published 
technical  documentation. 

ASC  X12.3  -  The  Data  Element  Fictionary  specifies  the  data 
elements  used  in  the  construction  of  the  segments  that  comprise 
the  transaction  sets  developed  by  ASC  XI 2. 

ASC  XI  2.5  -  The  Interchange  Control  Structure  provides  the 
interchange  control  segment  (also  called  an  envelope)  of  a  bead^i 
and  trailer  for  the  electronic  interchange  through  a  data  transmis¬ 
sion;  it  also  provides  a  structure  to  acknowledge  the  receipt  and 
processing  of  the  envelope. 

ASC  X12.6  -  The  Application  Control  Structure  defines  the  basic 
control  structures,  syntax  rules,  and  semantics  of  EDI. 

ASC  X12.22  -  The  Data  Segment  Directory  provides  the  defini¬ 
tions  and  specifications  of  the  segments  used  in  the  construction 
of  transaction  sets  developed  by  ASC  XI 2. 

The  DoD  convention  in  Section  3.4  conforms  to  the  above  stand¬ 
ards,  and  each  transaction  set  is  a  complete  document  to  the  extent 
possible.  For  further  clarification  of  acronyms,  abbreviations,  and 
codes,  refer  to  ASC  X12  published  technical  documentation.  For 
copies,  contact  either  the  OUSD  (A  &  T)  CALS/EDI  or  the  Data 
Interchange  Standards  Association,  Inc.,  Suite  355,  1800  Diagonal 
Road,  Alexandria,  VA  22314. 

3.2  CONTROL  SEGMENTS 

In  addition  to  the  communication  control  structure,  the  EDI  structure 
provides  the  standards  user  with  multiple  levels  of  control  to  ensure 
data  integrity.  It  does  so  by  using  header  and  trailer  coiitrol  segments 
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designed  to  identify  uniquely  the  start  aod  end  of  the  interchange 
functional  groups  and  transaction  sets.  The  relationship  of  these 
control  segments  is  shown  in  Figure  3  2-1  Control  Segment 
specifications  are  de&ned  in  Section  3.2.2. 

3.2.1  Description  of  Use 

The  interchange  header  and  trailer  segments  surround  one  or  more 
functional  groups  or  interchange-related  control  segments  and  per¬ 
form  the  following  functions: 

•  Define  the  data  element  s  -narators  and  data  segment  ter¬ 
minators 

•  Identify  the  sender  and  receiver 

•  Provide  control  information 

•  Allow  for  authorization  and  security  information. 

The  Interchange  Acknowledgment  Segment  is  used  to  acknowledge 
one  interchange  header  and  trailer  envelope  where  the  envelope 
surrounds  one  or  more  functional  groups.  (No  acknowledgment  is 
made  for  the  interchange  acknowledgment.) 

The  interchange  control  number  value  in  the  acknowledgment 
(TAl  segment)  is  the  same  as  that  for  the  ISA  segment  that  is 
being  aciuiowledged.  The  control  number  serves  as  a  link  between 
the  interchange  header  and  trailer  and  the  acknowledgment  of  that 
header  and  trailer. 

The  interchange  acknowledgment  does  not  report  any  status  on  the 
functional  groups  contained  in  the  interchange  and  is  separate 
from  the  communication  system’s  error  procedures. 

The  preparer  of  the  interchange  header  and  trailer  indicates  the 
level  of  acknowledgment  in  Data  Element  113,  Acknowledgment 
Requested.  If  an  acknowledgment  is  requested,  then  the  recipient 
must  return  an  acknowledgment.  If  not  requested,  none  should  be 
given. 

The  interchange  acknowledgment  control  segments  are  placed  after 
the  interchange  header  and  before  the  first  functional  group  or 
before  the  interchange  trailer  if  there  are  no  functional  groups. 

Control  segments  are  standard  for  all  implementation  conventions 
produced  for  the  Department  of  Defense.  Some  codes  associated 
with  individual  data  elements  within  the  control  segments  are 
unique  to  the  individual  transaction  set.  Others,  identify  the  ANSI 
version  and  release  in  which  the  convention  is  written. 
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Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Segment:  ISA  Interchange  Control  Header 

Purpose:  To  start  and  identify  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments. 

Data  Element  Summa 


DATA 

ELCMINT  NAMi 


ISA01  101  Authorization  information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Authorization  Information. 

00  No  Authorization  Information  Present  (No  Meaningful  Informatbn  in  IG2) 

ISA02  102  Authorization  Information  M  AN  10/10 

Information  used  for  additional  identification  or  authorization  of  the  sender  or  the 
data  in  the  interchange.  The  type  of  information  is  set  by  the  Authorization 
Information  Qualifier. 

Implementation  Note: 

If  no  authorization  information  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 

ISA03  103  Security  Information  Qualifier  M  ID  2/2 

Code  to  identify  the  type  of  information  in  the  Security  Information. 

01  Password 

iSA04  104  Security  Information  M  AN  10/10 

This  is  used  for  identifying  the  security  information  about  the  sender  or  the  data 
in  the  interchange.  The  type  of  information  is  set  by  the  Security  Information 
Qualifier. 

Implementation  Note: 

An  agreed  upon  password.  If  no  security  irrformation  is  agreed  to  by  trading  partners,  fill  field  with  blanks. 


ISA06 


ISA05  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  10  element  being  qualified. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

An  agreed  upon  designation  of  DoD  Activity  Address  Code  (DoDAAC )  or  other  code  coordirutted 
with  the  value-added  network  (VAN). 

ISA06  106  Interchange  Sender  ID  M  ID  15/15 

Identification  .  published  by  the  sender  for  other  parties  to  use  as  the 
receiver  ID  to  route  data  to  them.  The  sender  always  codes  this  number  in  the 
sender  ID  element. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC )  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  identification  code  qualified  by  IS  AOS  and 
coordinated  with  the  VAN. 

ISA07  105  Interchange  ID  Qualifier  M  ID  2/2 

Qualifier  to  designate  the  system/method  of  code  structure  used  to  designate  the 
sender  or  receiver  ID  element  being  qualified. 

ZZ  Mutually  Defined 
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Mandatory 


Code  Value  Implementation  Note: 

An  agreed  upon  designation  of  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated 
with  the  value-added  network  (VAN). 

ISA08  107  Interchange  Raceiver  ID  M  ID  15/15 

Identification  code  published  by  the  receiver  of  the  data.  When  sending,  it  is 
used  by  the  sender  as  their  sending  ID,  thus  other  parties  sending  to  them  will 
use  this  as  a  receiving  ID  to  route  data  to  them. 

Implementation  Note: 

Department  of  D^ense  activities  use  DoD  Activity  Address  Code  (DoDAAC)  or  other  code  coordinated  with 
the  value-added  network  (VAN).  Non-DoD  activities  use  ideruificmion  code  qualified  by  ISA05  and 
coordinated  with  the  VAN. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


ISA09  108  Interchange  Date  M  DT  6/6 

Date  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  YYMMDD 

ISA10  109  Interchange  Time  M  TM  4/4 

Time  of  the  interchange. 

Implementation  Note: 

Assigned  by  translation  software.  HHMM 

ISA11  110  Interchange  Control  Standards  Identifier  M  ID  1/1 

Code  to  identify  the  agency  responsible  for  fhe  control  standard  used  by  the 
message  that  is  enclosed  by  the  interchange  header  and  trailer. 

U  U.S.  EDI  Community  of  ASC  XI 2,  TDCC,  and  UCS 

ISA12  111  Interchange  Control  Version  Number  M  ID  5/5 

This  version  number  covers  the  interchange  control  segments  and  the  functional 
group  control  segments. 

00303  Draft  Standard  for  Trial  Use  Approved  for  Publication  by  ASC  X12  Procedures 
Review  Board  Through  October  1992 

Code  Value  Implementation  Note: 

Version  ID  as  defined  or  agreed  upon  by  the  trading  partners. 

ISA13  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

ISA14  113  Acknowledgment  Requested  M  ID  1/1 

Code  sent  by  the  sender  to  request  an  interchange  acknowledgment. 

0  No  Acknowledgment  Requested 
1  Interchange  Acknowledgment  Requested 

ISA15  114  Test  Indicator  M  ID  1/1 

Code  to  indicate  whether  data  enclosed  by  this  interchange  envelope  is  test  or 
production. 

P  Production  Data 
T  Test  Data 
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Mandatory 


Code  Value  Implementation  Note: 

Assigned  by  translation  software. 

ISA16  115  Subelemant  Separator  M  AN  1/1 

This  is  a  field  reserved  tor  future  expansion  in  separatirtg  data  element 
subgroups.  (In  the  interest  of  a  migration  to  international  standards,  this  should 
be  different  from  the  data  element  separator). 

Implementation  Note: 

Use  character 
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Segment:  GS  Functional  Group  Header 

Purpose:  To  indicate  the  beginning  of  a  functional  group  and  to  provide  control 
information 


Syntax:  The  data  interchange  control  number  (GS06)  in  this  header  must  be 
identical  to  the  same  data  element  in  the  associated  Functional  Group 
Trailer  (GE02). 

Comment:  A  functional  group  of  related  transaction  sets,  within  the  scope  of  X12 

standards,  consists  of  a  collection  of  similar  transaction  sets  enclosed  by 
a  functional  group  header  and  a  functional  group  trailer. 


Mandatory 


Mandatory 


_ Data  Element  Summary _ 

KEF.  DATA 

DES. _ ELEKEWT  NAME  _ _  _ ATTWOTES 

GS01  479  Functional  Identifier  Code  M  ID  2/2 

Code  identifying  a  group  of  application  related  Transaction  Sets. 

Implementation  Note: 

Choose  the  code  value  appropriate  to  the  information  coraent  of  the  functional  group.  See  XI 2  Dictionary  for 
source  code  list. 

SP  Specifications/Technical  Information  (841) 

GS02  142  Application  Sender’s  Code  M  AN  2/1 S 

Code  identifying  party  sending  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  For  increased  security,  non-DoD  code  should  differ  from  that 
used  in  ISA06. 


Mandatory 


GS03  124  Application  Receiver's  Code  M  AN  2/15 

Code  identifying  party  receiving  transmission.  Codes  agreed  to  by  trading 
partners. 

Implementation  Note: 

Department  of  Defense  activities  use  DoD  Activity  Address  Code  (DoDAAC).  Non-DoD  activities  use 
identification  code  assigned  by  DoD  activity.  For  increased  security,  non-DoD  code  should  differ  from  that 
used  in  ISA08. 


Mandatory 


Mandatory 


Mandatory 


Mandatory 


GS04 

373 

Date 

Date  sender  generated  a  transaction  set. 

M 

DT 

6/6 

GS05 

337 

Time 

Time  expressed  in  24'hour  clock  time. 

M 

TM 

4/6 

GS06 

28 

Group  Control  Number 

Assigned  number  originated  and  maintained  by  the  sender. 

M 

NO 

1/9 

Implementation  Note: 

Assigned  by  translation  software. 

GS07 

455 

Responsible  Agency  Code 

M 

ID 

1/2 

Code  used  in  conjunction  with  Data  Element  480  to  identify  the  issuer  of  the 
standard. 


X  Accredited  Standards  Committee  XI 2 
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Code  Value  Implementation  Note: 

Indicates  that  an  ANSI  XJ2  standard  is  being  transmitted. 


Mandatory 


GS08  480  Version/Release/Industry  ID  Code  M  ID  1/12 

Code  indicating  the  version,  release,  subrelease  and  industry  identifier  of  the  EOl 
standard  being  used.  Positions  1-3,  version  number;  positions  4-6,  release  and 
subrelease  level  of  versbn;  positions  7-12,  industry  or  trade  association  identifier 
(optionally  assigned  by  user). 


003030  Draft  Standards  Approved  by  ASC  X12  Through  October  1992. 

Code  Value  Implementation  Note: 

Code  value  agreed  to  by  trading  partners.  See  X 12  Dictionary  for  source  code  list. 
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Segment:  GE  Functional  Group  Trailer 

Purpose:  To  indicate  the  end  of  a  functional  group  and  to  provide  control 
information 

Syntax:  The  data  interchange  control  number  (GE02)  in  this  trailer  must  be 

identical  to  the  same  data  element  in  the  associated  Functional  Group 
Header  (GS06). 

Comment:  The  use  of  identical  data  interchange  control  numbers  in  the  associated 
functional  group  header  and  trailer  is  designed  to  maximize  functional 
group  integrity.  The  control  number  is  the  same  as  that  used  in  the 
corresponding  header. 


Mandatory 


Data  Element  Summary _ 

ATmmrrfs 


GE01  97  Number  of  Transaction  Sets  Included  M  NO  1/6 

Total  number  of  transaction  sets  included  in  the  functional  group  or  interchange 
(transmission)  group  terminated  by  the  trailer  containing  this  data  element. 

Implementation  Note: 

Assigned  by  translation  software. 


Mandatory 


GE02  28  Group  Control  Number  M  NO  1/9 

Assigned  number  originated  and  maintained  by  the  sender. 


Implementation  Note: 

Assigned  by  the  translation  software.  This  control  number  must  match  the  control  number  of  the  preceding 
GS06  control  number. 
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Segment:  lEA  Interchange  Control  Trailer 

Purpose:  To  define  the  end  of  an  interchange  of  one  or  more  functional  groups 
and  interchange-related  control  segments. 


Mandatory 


Mandatory 


_ Data  Element  Summary  _ 

RfF.  DATA 

DKS.  ItBMPff  WAi«6  ATTWOTES 

IEA01  116  Number  of  Included  Functional  Groups  M  NO  1/5 

A  count  of  the  number  of  functional  groups  included  in  a  transmission. 

Implementation  Note: 

Assigned  by  translation  software. 

IEA02  112  Interchange  Control  Number  M  NO  9/9 

This  number  uniquely  identifies  the  interchange  data  to  the  sender.  It  is  assigned 
by  the  sender.  Together  with  the  sender  ID  it  uniquely  identifies  the  interchange 
data  to  the  receiver.  It  is  suggested  that  the  sender,  receiver,  and  all  third  parties 
be  able  to  maintain  an  audit  trail  of  interchanges  using  this  number. 

Implementation  Note: 

Assigned  by  the  translation  software.  This  control  number  must  match  the  number  that  occurs  in  ISAI3. 
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EXAMPLE  •  SPEgRCAPONS/TECHNlCAL  DOCUMENTATION 

841 THANSACTIQN  SET  (RETERENCE) 


ASC  X12  EDI  FORMAT  PEnNITlQN 

SE*841*0001  This  is  ma  841  transaction  set  with  a  control  Dumber  of  0001. 

SPI*90*TN*841R£F001****00*SD*06  The  data  being  reference  arc  classified  goeeminent  non<lassilled 
n/l  (Code  90).  The  transaction  set  reference  number  (Code  TN)  is 

841REF001.  This  is  an  original  transmission  (Code  00)  of  data  in 
support  of  an  RFQ  (Code  SD).  The  data  have  a  commercial 
protection  rc<)uirement  of  company  proprietary  (Code  06). 

REF«KS«N0001993Q1234  n/l  The  solicitation  number  (Code  KS)  to  whkh  the  daU  in  this 

transaction  set  pertain  u  N0001993Q1234. 

The  date  of  the  solicitation  (Code  993)  is  June  IS,  1993. 

The  reference  number  of  this  transaction  set  (Code  TN)  is 
841REF001. 


The  creation  date  of  tiib  transaction  set  (Code  097)  is  June  16, 
1993. 

The  nnitpie  reference  number  (Code  ZZ)  of  the  transaction  set  to 
which  the  data  In  this  transaction  set  pertain  is  RFQ2468. 

The  date  of  die  referenced  transaction  set  (Code  368)  is  June  16, 
1993 


The  buying  actirity  (Code  BY)  as  specified  by  DoDAAC  (Code  10) 
N00019. 


The  selling  party  (Code  SE)  as  specified  by  CAGE  code  (Code  33) 
CD345. 


The  configuration  manager  (Code  DG)  as  specified  by  DoDAAC 
N4S678. 

PER*IC*  Joe  Loais*EM*DG8YS892  n/l  The  point  of  contact  (Code  IC)  at  the  originator's  actirity  is  Joe 

Louis.  His  electronic  mail  address  (Code  EM)  is  DG8YS892. 

HL*1**A*1  n/l  This  is  the  first  iteration  of  the  HL  Loop,  as  specified  by  the 

number  1.  It  has  no  parent  The  hierarchical  ferel  is  tte  assonbly 
(Code  A).  It  has  subordinate  levels. 

SPI*90*DD*12£2211-877***F  n/I  The  data  being  proride  is  government  non-classified  (Code  90).  It 

is  a  Engmeering  Data  List  (Code  DD)  with  a  reference  number  of 
12E2211<877.  It  is  released  for  quotation  (Code  F). 


DTM«993*930615n/I 
REF^«841R£F001  nA 

DTM«097*930616n/l 

R£F«ZZ«RFQ2468  n/l 

DTM*368«930616  n/l 

N1«BY**10*N00019  n/l 

N1*SE**33*CD345  n/l 

N1*DG*«10*N45678  n/l 
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LW**F7*FBH1A*FS*168001(»39*PD 
•Panel,  Ground  ClMck«ZZ*FJ  n/l 


The  end  Hem  appUcatkm  (Code  FT)  is  FBlllA.  The  NSN  (Code 
FS)  is  1680010639.  The  part  number  description  (Code  FD)  is 
Panel,  Ground  Check.  The  applicable  Data  Tech  organization 
Code  (Code  ZZ)  is  FJ. 


N1*33**10*N78961  n/l 


The  Data  Tech  entity  (Code  33)  as  specified  by  DoDAAC  (Code  10) 
N78961. 


N1*ZE**33*B1234  n/I 


HL*2*1*U*1  n/I 


The  Manufacturer  (Code  ZE)  as  specified  by  CAGE  code  (Code 
33)  B1234. 

The  second  iteration  of  the  HL  Loop  as  specified  by  the  number  2. 
Its  parent  is  HL  1.  The  hierarchical  kvel  is  the  subassembly  (Code 
U).  It  has  subordinate  levels  (Code  1). 


SPI*92*DG*12E2211***A***02  n/I 


Drawing  (Code  DG)  number  12E2211  is  classified  government 
confidential  (Code  92).  It  is  an  approved  Version  (Code  A)  and 
has  a  commercial  protection  requirement  of  company  confidential 
(Code  02). 


RDT*E*AY*007*921215  n/l 


LIN**PD*Panel  Assembly  n/l 


HL*3*2*I*0*  n/l 


SPI*90*ZZ«LM12E2211«BiU  of 
Material  n/I 

HL*4*1*U*1  n/l 


SPI*90*DG*12E2213***D***06  n/l 


LIN*PD«Bracketii/l 


Nl*ZE**33*GB5678n/l 


This  is  revision  (Code  E)  "AY",  with  an  effective  date  (Code  007)  of 
December  15, 1992. 

The  item  description  (Code  FD)  is  Panel  Assembly. 

This  is  the  third  iteration  of  the  HL  segment  as  specified  by  the 
number  3.  Its  parent  is  HL  2.  The  hierarchical  level  is  the  item 
(Code  I).  It  has  no  child  (Code  0). 

The  item  number  (Code  ZZ),  LM12E2211,  b  a  Bill  of  Material  and 
b  government  non-classified  (Code  90). 

Thb  b  the  fourth  iteration  of  the  HL  segment  as  specified  by  the 
number  4.  Its  parent  b  HL  1.  The  hierarchical  level  b 
subamembly  (Code  U).  It  has  a  child  (Code  1). 

The  drawing  (Code  DG)  number  b  12E2213.  It  b  government  non* 
classified  (Code  90)  and  the  commercial  protection  level  b  company 
proprietary  (Code  06).  It  b  released  for  production  (Code  D). 

The  item  description  (Code  PD)  b  bracket 

The  Manufacturer  (Code  ZE)  has  a  CAGE  code  (Code  33)  of 
GBS678. 


HL*5*4*I*0*  nfi 


SPI*90*S3*Z-R701  n/I 


Thb  b  the  fifth  iteration  of  the  HL  segment  as  specified  hy  the 
numbers.  Its  parent  b  HL  4.  The  hierarchical  level  b  the  item 
(Code  I).  It  has  no  child  (Code  0). 

The  specification  (Code  S3)  number  b  Z*R701.  It  b  government 
non-classified  (Code  90). 


RDT*H*As-Builin/l 


The  Version  level  (Code  H)  b  "As-BulH." 
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SE*31«0001 


This  trmiuKtkm  set,  who«  coatrol  number  ii  0001,  eontotei  31 

segments. 
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841  Specifications/T echnical  Information 

This  Draft  Standard  for  Trial  Use  contains  the  format  and  establishes  the  data  contents  of  the 
Specifications/Technical  Information  Transaction  Set  (841 )  tor  use  within  the  context  of  an 
Electronic  Data  Interchange  (EDI)  environment.  The  transaction  set  can  be  used  to  transmit 
specifications  or  technical  information  between  trading  partners.  It  can  be  used  to  allow  EDI 
trading  partners  the  ability  to  exchange  a  complete  or  partial  technical  description  of  a  product, 
process,  service,  etc.  over  the  same  path  as  any  other  EDI  transaction.  The  detail  area  can 
include  graphic,  text,  parametric,  tabular,  image,  spectral,  or  audio  Lata.  A  transmission  includes 
identification  information  to  assist  the  receiver  in  interpreting  and  utilizing  the  information 
included  in  the  transaction. 

Further  action  as  a  consequence  of  the  receipt  and  initial  processing  of  the  specification  or  other 
technical  data  may  or  may  not  require  human  intervention.  The  transmission  and  receipt  of  the 
data  may  require  private  agreement  between  the  trading  partners  to  automate  the  receipt  of  the 
data. 

The  total  transaction  must  be  in  the  general  form  of  all  ASC  XI 2  transactions  so  that  an  EDI 
computer  system  will  be  able  to  automatically  recognize  it  as  a  Specification/Technical 
Information  Transaction  Set  and  pass  it  on  for  processing  of  the  data  itself.  The  transaction  set 
is  not  media  dependent. 

The  detail  area  of  the  Specification/Technical  Information  Transaction  Set  provides  a  structure 
which  allows  for  the  exchange  of  a  variety  of  spedlication  information.  For  example,  if  the 
transaction  contains  information  describing  a  complete  assembly,  it  would  be  necessary  to 
include  the  assembly  model,  the  models  (or  each  of  the  individual  parts,  and  the  associated 
specifications.  In  the  case  of  a  process  it  may  be  necessary  to  transmit  the  specification  of  the 
product  along  with  (he  specifications  of  the  process  and  raw  materials.  This  transaction  set  can 
also  be  linked  to  other  transaction  sets 

This  transaction  set  is  not  limited  to  a  specific  transmission  protocol  and  uses  other  standards  as 
applicable  where  they  do  not  conflict  with  these  requirements  for  specification  transaction. 
Implementation  Notes 

1.  This  dretft  implementation  convention  is  designed  to  be  used  to  reference  specifications/technical 
information  that  is  applicable  to  the  production  of  an  item  and  is  associated  with  an  840  transaction  set 
(Request  for  Quotation). 

2.  The  841  transaction  set  may  contain  a  drawing  list  that  may  or  may  not  be  included  in  an  associated  840 
transaction  set  (Request  for  Quotation)  or  other  transaction  set.  The  840  transaction  set  can  carry  a  drawing 
list  in  the  N9  segment  at  the  Header  level,  but  more  likely  the  list  will  be  included  in  the  N9  segment  at  the 
Detail  level.  The  DoD  ImplemerUation  Guide  for  the  840  transaction  set  includes  the  N9  segments  and  loops 
at  the  Header  and  Detail  level.  TheN9  segmera  will  include  the  code  for  drawings  ( 128  data  element.  Code 
DG)  to  support  a  cross  reference  list  of  drawings  from  an  Engineering  Data  List  for  an  associated  841 . 

When  840  and  841  transaction  sets  are  issued  together,  the  BQfT  segment  in  the  Header  level  of  the  840  will 
tie  a  solicitation  number  to  the  REF  segment  in  the  Header  level  of  the  841.  Reference  segmeras  in  both 
transaction  sets  can  contain  unique  transaction  set  control  numbers  to  further  tie  the  transaction  sets 
together  if  necessary. 


PAGES  POS.« 

5  010 

6  020 
N/U  030 


Table  1 


SEG.  ID 

NAME 

REa  DES. 

MAX  USE 

LOOP  REPEAT 

ST 

Transaction  Set  Header 

M 

1 

Loopfo-sn 

>1 

SPI 

Specification  Identifier 

M 

1 

RDT 

Revision  Date/Time 

O 

>1 
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N/U  150 
N/U  160 

N/U  170 
N/U  180 
N/U  190 
N/U  200 
N/U  201 
N/U  210 
N/U  220 

N/U  230 
N/U  240 
N/U  250 

N/U  260 
N/U  270 
N/U  280 

N/U  282 
N/U  283 

N/U  2M 
N/U  285 
N/U  286 
N/U  287 

N/U  290 
N/U  300 
N/U  310 


PAGE*  POS.» 
28  010 


DEPARTMENT  OF  DEFB4SE 
DRAFT  IMPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  00303000D 


Military  Standard  1840- A  Record  Definition 
Binary  Data 

Characteristic/Class  ID 
Unit  Detail 
Test  Method 

Physical  Sample  Description 
Conditional  Sampling  Sequence 
Sampling  Parameters  lor  Summary  Statistics 
Message  Text 


t^ip*HyC2pl8tl^ 

Measurements 
Date/Time  Reference 

Reference  Numbers _ 

L00P)0*mX2CU6TA 

Statistics 

Date/Time  Reference 
Reference  Numbers 

Conditional  Sampling  Frequency 
Loop  Header 

Characteristic/Class  ID 
Measurements 

Statistics _ 

Loop  Trailer _ 

Loopio-wjtao/eFt 
Electronic  Format  Identification 
Military  Standard  1S40-A  Record  Definition 
Binary  Data 


Table  3 

sea  to  NAME 

REa  DE5.  MAX  USE 

LOOPRB>EAT 

SE  Transaction  Set  Trailer  M  1 

NOTES: 

2/010  To  be  meaningful,  at  least  one  of  the  SPI,  PID,  REF.  MEA,  EFI  or  CID  loops 
must  be  present  with  each  occurence  of  the  HL  loop. 

2/020  The  HL  segment  may  be  used  to  define  the  hierarchical  relationship  of  product-re¬ 
lated  specifications  reported  in  the  associated  HL  loop.  Product-related  specifica¬ 
tions  may  refer  to  the  product  in  its  entirety  or  to  subunits  of  the  product.  For 
example,  if  the  top  level  refers  to  an  assembly,  the  second-level  HL  segment 
may  refer  to  parts  or  subassemblies  of  the  top  assembly.  This  pattern  may  be 
repeated  as  often  as  required. 

2/170  The  CID  segment  may  be  used  to  define  either  a  general  class  of  properties, 
such  as  physical  properties,  or  an  individual  property  within  a  class.  The  CID 
loop  allows  the  user  the  ability  to  define  specifications  such  as  the  properties  of 
the  item  or  class,  the  environmental  conditions  under  which  the  specifications 
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apply,  the  test  methods  to  be  used,  and  other  parameters  related  to  properties 
within  the  current  HL  hierarchical  level. 

2/201  The  sampling  sequence  specified  in  the  CSS  segment  will  take  precedence  over 
any  other  sampling  rate  (PSD03,  PSD09,  SPS06,  CSF02,  and  CSF03)  from  the 
point  the  CSS01  event  occurs  until  the  specified  sequence  is  completed. 

2/201  If  no  other  sampling  is  specified,  then  only  the  sampling  indicated  in  this  segment 
is  performed  when  the  CSS01  event  occurs. 

2/282  The  sampling  rate  specified  is  the  CSF  segment.  It  would  take  precedence  over 
the  normal  sampling  rate  specified  in  PSD03  while  the  conditions  of  the  CSF  seg¬ 
ment  are  satisfied,  but  would  NOT  take  precedence  over  the  sampling  sequence 
activated  by  the  proposed  CSS  segment. 

2/282  If  no  other  sampling  rate  is  specified,  then  the  only  sampling  indicated  in  the  CSF 
segment  is  performed  while  the  CSF  conditions  are  met.  Sampling  will  cease 
when  the  conditions  are  no  longer  met. 

2/282  Conditional  values  specified  in  DE  740  (Range  Minimum)  will  be  interpreted  as 
“greater  than  or  equal  to  this  value.”  Values  specified  in  DE  741  (Range  Maxi¬ 
mum)  will  be  interpreted  to  mean  “less  than  or  equal  to  this  value." 

2/282  Repetitions  of  the  CSF  loop  allow  several  frequency  changes  (and  the  conditions 
that  would  trigger  those  changes)  to  be  specified. 

2/282  If  the  conditions  are  such  that  several  CSF  values  are  activated  at  the  same 
time,  the  value  with  the  highest  sampling  rate  shall  prevail. 

2/284  Either  the  MEA  segment  or  the  STA  segment  must  occur,  but  not  both. 

2/284  The  CID  loop  within  the  CSF  loop  is  used  to  specify  the  coriditions  that  will  trig¬ 
ger  activation  of  the  conditional  value  in  the  CSF  segment. 

2/284  Repetitions  of  the  CID  loop  will  have  an  implied  logical  AND  between  the  condi¬ 
tions  set  in  each  iteration. 

2/285  The  elements  of  the  CID  segment  identify  the  conditional  property.  If  the  property 
is  a  measurement  from  within  the  manufacturing  process  of  a  plant  environment, 
rather  than  the  product,  the  segment  also  identifies  the  location  where  the  meas¬ 
urements  are  to  be  observed. 

2/286  If  the  condition  is  based  on  single  test  measurements,  the  MEA  segment  is  used 
to  specify  the  units  of  measure,  and  the  open  or  closed  numeric  range  of  the  con¬ 
ditional  test. 
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Mandatory 


Mandatory 


Mandatory 


Segment:  ST  Transaction  Set  Header 
Level:  Header 

Loop:  _ 

Usage:  Mandatory 
Max  Use:  1 

Purpose:  To  indicate  the  start  of  a  transaction  set  and  to  assign  a  control  number 

Semantic:  The  transaction  set  identifier  (ST01 )  used  by  the  translation  routines  of 
the  interchange  partners  to  select  the  appropriate  transaction  set 
definition  (e.g.,  810  selects  the  invoice  transaction  set). 


_ Data  Element  Summar 

DATA 

tLaoir  KAMI _ 

143  T  ransaction  Set  Idantifier  Code 

Code  uniquely  identifying  a  Transaction  Set. 

841  XI  2.51  Specifications/Technical  Information 


ATTWUTIS  _ 

M  ID  3/3 


ST02  329  Transaction  Sat  Control  Number  M  AN  4/9 

Identifying  control  number  that  must  be  unique  within  the  transaction  set 
functional  group  assigned  by  the  originator  for  a  transaction  set 

Implementation  Note: 

This  unique  control  number  is  assigned  by  the  originator  of  the  transaction  set  or  by  the  originator's 
application  program.  This  same  rutmber  is  carried  in  SE02. 
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SPI  •  SPECIFICATION  IDENTIFIER 


Mandatory 


Segment;  SPI  Specification  identifier 
Level:  Header 
Loop:  SPI  Repeat:  >1 
Usage:  Mandatory 
Max  Use:  1 

Purpose:  To  provide  a  description  of  the  included  specification  or  technical  data 
items. 


Mandatory 


Mandatory 


Mandatory 


Not  Uaad 
Not  Uaad 
Not  Uaad 
Raquirad 


_ Data  Element  Summary _ 

HEP.  DATA 

PIS. _ ELPIEMT  WAMt _ ATTIWauTtS 

SPI01  786  Security  Level  Code  M  ID  2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  hse  any  code. 

2.  If  the  data  being  referenced  have  both  a  govertmeni  security  classification  and  a  commercial  security 
protection  requirement,  then  this  data  element  will  carry  the  government  security  classifi  -ation  code  and  the 
commercial  security  protection  code  will  be  carried  in  SPI09. 

3.  if  the  data  being  referenced  have  only  one  protection  requiremeru,  then  this  data  elerrtent  can  carry  either 
the  government  security  classification  or  the  commercial  security  protection  code. 

4.  Use  this  data  element  to  indicate  the  highest  protection  level  (government  or  commercial)  of  the  data 
being  referenced.  Use  the  SPI  segment  at  the  Detail  level  to  indicate  the  protection  level  of  iruiividual  data 
items. 

SPI02  128  Reference  Number  Qualifier  M  ID  2/2 

Code  qualifying  the  Reference  Number. 

TN  Transaction  Reference  Number 
Code  Value  Implementation  Note: 

Use  Code  TN  for  the  unique  reference  number  of  this  transaction  set. 

SPI03  127  Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

Implementation  Note: 

This  is  the  unique  reference  number  of  this  transaction  set. 


SPI04 

790 

Entity  Title 

0 

AN 

1/132 

SPiOS 

791 

Entity  Purpose 

0 

AN 

1/80 

SPI06 

792 

Entity  Status  Code 

o 

ID 

1/1 

SPI07 

353 

Transaction  Set  Purpose  Code 

Code  identifying  purpose  of  transaction  set. 

0 

ID 

2/2 

Implementation  Note: 

Use  any  appropriate  listed  code. 

00  Original 
01  Cancellation 
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Code  Value  Implementation  Note: 

Use  Code  0]  when  cancelling  an  84 1  iransaclum  set  referencing  technical  documentation  When 
Code  01  is  used,  only  the  HL  segment  (HLOl  and  HL03 )  at  the  Detail  level  (Table  2 1  is  needed. 

02  Add 
03  Delete 
04  Change 


Optional 


SPI08  75?  Report  Type  Code  O  ID  212 

Code  indicating  the  title  or  contents  of  a  document,  report  or  supporting  item 

SD  Support  Data  for  a  Request  for  Quote 

Code  Value  Implementation  Note: 

Use  Code  SD  to  indicate  this  transaction  set  is  providing  techmeal  data  in  support  of  a  solicitation. 


Optional 


Not  Used 
Not  Used 
Not  Used 


SPI09  786  Security  Level  Code  O  >0  212 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 

Implementation  Notes: 

1.  Use  this  data  element  ONLY  when  SPlOl  is  Code  90,  92,  05,  94,  or  99,  and  the  data  being  referenced  also 
have  a  commercial  security  protection  requirement. 

2,  Use  this  data  element  to  indicate  the  hig‘test  level  of  commercial  security  protection  assigned  to  the  date 
being  referenced.  Use  the  SPI  segment  at  the  Deia.1  level  to  indicate  the  commercial  security  protection  of 
individual  data  items. 

00  Company  Non-Classified 
01  Company  Internal  Use  Only 
02  Company  Confidential 

03  Company  Confidential,  Restrictiiid  (Need  to  Know) 

04  Company  Registered  (Signature  Required) 

05  Personal 

09  Company  Defined  (T rading  Partner  Level) 


SPI10 

559 

Agency  Qualifier  Code 

0 

ID 

212 

SPI11 

916 

Code  List  Reference 

O 

AN 

1/6 

SPI12 

554 

Assigned  Number 

0 

NO 

1/6 

Dcr  -JULYgitigs 


n 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 


841  •  REFERENCE 

ANSI  ASC  X12  VERSION/RELEASE  003030DOD_  NTE  •  NOTE/SPECIAL  INSTRUCTION 


Optional 


Segment:  NTE  Note/Special  instruction 
Level:  Header 
Loop:  SPI 
Usage:  Optional 
Max  Use:  >1 


Purpose:  To  transmit  information  in  a  free-form  format,  if  necessary,  for  commenf 
or  special  instruction 

Comment:  The  NTE  segment  permits  free-form  information/data  which,  under  ANSI 
X12  standard  implementations,  is  not  machine  processable.  The  use  of 
the  “NTE"  segment  should  therefore  be  avoided,  if  at  all  possible,  in  an 
automated  environment. 


Implementation  Note: 

Use  this  segment  to  provide  informa  ion  pertinent  to  the  entire  transaction  set.  To  provide 
information  relative  to  a  specific  dati  item,  use  the  MSG  segment  in  Table  2. 


Optional 


Mandatory 


_ Data  Element  Summary _ 

MF.  DATA 

DCS.  ELtMEKT  NAME _ _ ATnilEUTES 

NTE01  363  Note  Reference  Code  O  ID  3/3 

Code  identifying  the  functional  area  or  purpose  for  which  the  note  applies. 

GEN  Entire  T ransaction  Set 
Code  Value  Implementation  Note: 

Use  Code  GEN  for  any  notes  that  relate  to  the  entire  transaction  set. 

NTE02  3  Free  Form  Message  M  AN  1/60 

Free-form  text. 
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Required 


Segment:  REF  Reference  Numbers 
Level:  Header 

Loop:  SPI/REF  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  specify  identifying  numbers. 

Syntax:  R0203  —  At  least  one  of  REF02  or  REF03  is  required. 

Implementation  Notes: 

1.  At  least  one  REF  segment  is  required  using  Code  KS. 

2.  Additional  repititions  of  the  REF  segment  may  be  used  to  provide  other  applicable  reference 
numbers. 


Mandatory 


Conditional 


Not  Used 


Data  Element  Summa 


DATA 

ELPHeWT  NAME 


REF01  128  Reference  Number  Qualifier  M  ID  2/2 

Code  qualifying  the  Reference  Number. 

C4  Change  Number 
Code  Value  Implementation  Note: 

Use  Code  C4  for  the  contract  modification  number  to  which  the  data  referenced  in  this  transaction 
set  pertain. 

CT  Contract  Number 
Code  Value  Implementation  Note: 

Use  Code  CT  for  the  contract  number  to  which  the  data  referenced  in  this  transaction  set  pertain. 
KS  Solicitation 

Code  Value  Implementation  Note: 

Use  Code  KS  to  specify  the  solicitation  number  to  which  the  data  referenced  in  this  transaction  set 
pertain. 

TN  Transaction  Reference  Number 
Code  Value  Implementation  Note: 

Use  Code  TN  for  the  unique  reference  number  of  this  transaction  set. 

ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  2Z  for  the  unique  reference  number  of  the  transaction  set  to  which  the  data  in  this 
transaction  set  pertain. 

REF02  127  Reference  Number  C  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

REF03  352  Description  C  AN  1/80 
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Optional 


Segment:  DTM  Oate/Time  Reference 
Level:  Header 
Loop:  SPI/REF 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  specify  pertinent  dates  and  times 
Syntax:  R0203  —  At  least  one  of  DTM02  or  DTM03  is  required. 


Mandatory 


Conditional 

Not  Used 
Not  Used 
Not  Used 


_ Data  Element  Summary _ 

RCF.  DATA 

OtS. _ ELCMEMT  WAillE  ATmfUTgS 

DTM01  374  Date/Time  Qualifier  M  ID  3/3 

Code  specifying  type  of  date  or  time,  or  both  date  and  time. 

092  Contract  Effective 
Code  Value  Implementation  Note: 

When  REFOl  is  Code  CT,  use  Code  092  to  indicate  the  date  of  the  contract  specified  in  REF02. 

097  T ransaction  Creation 
Code  Value  Implementation  Note: 

When  REFOl  is  Code  TN,  use  Code  097  to  indicate  the  creation  date  of  this  transaction  set . 

152  Effective  Date  of  Change 
Code  Value  Implementation  Note: 

When  REFOl  is  Code  C4,  use  Code  152  to  indicate  the  date  of  the  contract  modification  specified 
inREF02. 

368  Submittal 

Code  Value  Implementation  Note: 

When  REFOl  is  Code  ZZ,  use  Code  368  to  indicate  the  date  of  the  840  transaction  set  specified  in 
REF02. 


993  Request  for  Quotation 
Code  Value  Implementation  Note: 

When  REFOl  is  Code  KS,  use  Code  993  to  indicate  the  date  of  the  solicitation  specified  in  REF02. 


DTM02 

373 

Date 

Date  (YYMMDD). 

C 

DT 

6/6 

DTM03 

337 

Time 

C 

TM 

4/6 

OTM04 

623 

Time  Code 

0 

ID 

2/2 

DTM05 

624 

Century 

0 

NO 

2/2 
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Segment:  N1  Name 
Level:  Header 


Optional 


Loop:  SPI/N1  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 


Purpose:  To  identify  a  party  by  type  of  organization,  name  and  code 

Syntax:  1.  R0203  —  At  least  one  of  N1 02  or  N1 03  is  required. 

2.  P0304  —  If  either  N1 03  or  N1 04  is  present,  then  the  other  is  required. 

Comment:  This  segment,  used  alone,  provides  the  most  efficient  method  of 

providing  organizational  identification.  To  obtain  this  efficiency  the  "ID 
Code"  (N1 04)  must  provide  a  key  to  the  table  maintained  by  the 
transaction  processing  party. 

Implementation  Note: 

Whenever  possible,  identification  and  address  information  should  be  described  using  NIOI.NIOS, 
and  N104.  Use  NI02  and  segments  N2  through  N4  when  this  information  cannot  be  provided  by 
use  of  a  CAGE  code  or  a  DoDAAC. 


Mandatory 


Conditional 


Conditional 


_ Data  Element  Summary _ 

mr.  DAT« 

0€S.  ILPICKT  NAMt  ATTimUTIS 

N101  98  Entity  Identifier  Code  M  ID  2/2 

Code  identifying  an  organizational  entity,  a  physical  location,  or  an  individual 

BY  Buying  Party  (Purchaser) 

DG  Design  Engineering 

Code  Value  Implementation  Note: 

Use  Code  DG  to  identify  a  corfiguration  manager. 

SE  Selling  Party 


N102 

93 

Name 

Free-form  name. 

C 

AN 

1/35 

N103 

66 

Identification  Code  Qualifier 

C 

iD 

1/2 

Code  designating  the  system/method  of  code  structure  used  for  Identification 
Code  (67). 

10  Department  of  Defense  Activity  Address  Code  (DODAAC) 

33  Commercial  and  Government  Entity  (CAGE) 


Conditional 


N104  67  Identification  Code 

Code  identifying  a  party  or  other  code. 


C  AN  2/17 
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Optional 


Segment:  N2  Additional  Name  Information 
Level:  Header 
Loop:  SPI/M 
Usage:  Optional 


841  • REFERENCE 
N2  •  ADDITIONAL  NAME  INFORMATION 


Max  Use:  2 

Purpose:  To  specify  additional  names  or  those  longer  than  35  characters  in  length 

Implementation  Note: 

Use  of  this  segment  is  not  necessary  when  the  cited  entity  can  be  described  by  use  of  a  CAGE  code 
or  a  DoDAAC. 


Mandatory 


Optional 


Data  Element  Summary 


MF. 

DCS. 

DATA 

ELOKKT 

NAME 

ATTfUElfTES 

N201 

93 

Name 

Free-form  name. 

M 

AN  1/35 

N202 

93 

Name 

Free-form  name. 

0 

AN  1/35 
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841  •  REFERENCE 

N3  •  ADDRESS  INFORMATION  ANSI  ASC  X12  VERSION/RELEASE  003030000. 


Optional 


Segment:  N3  Address  Information 
Level:  Header 
Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  2 

Purpose:  To  specify  the  location  of  the  named  party 

Implementation  Note: 

Use  of  this  segment  is  not  necessary  when  the  cited  entity  can  be  described  by  use  of  a  CAGE  code 
oraDoDAAC. 


Mandatory 

Optional 


Data  Element  Summary 


HCP. 

Ofs. 

DATA 

tLEMorr 

NAME 

ATnUBt/TES 

N301 

166 

Address  Information 

Address  information 

M 

AN 

1/35 

N302 

166 

Address  Information 

Address  information 

O 

AN 

1/35 
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N4  •  GEOGRAPHIC  LOCATION 


Optional 


Segment:  N4  Geographic  Location 
Levei:  Header 
Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  specify  the  geographic  place  of  the  named  party 

Syntax:  1.  R01 05  —  At  least  one  of  N401  or  N405  is  required. 

2.  P0506  —  If  either  N405  or  N406  is  present,  then  the  other  is  required. 

Comments:  1.  A  combination  of  either  N401  through  N404  (or  N405  and  N406)  may 
be  adequate  to  specify  a  location. 

2.  N402  is  required  only  if  city  name  (N401 )  is  in  the  USA  or  Canada. 
Implementation  Note: 

Use  of  this  segment  is  not  necessary  when  the  cited  entity  can  be  described  by  use  cf  a  CAGE  code 
or  a  DoDAAC. 


Conditionai 

Optional 

Optional 

Optional 

Conditional 

Conditional 


Data  Element  Summary 


MtF. 

DtS. 

DATA 

iLBICKT 

NAME 

N401 

19 

City  Name 

Free-form  text  for  city  name. 

C 

AN  2/30 

N402 

156 

State  or  Province.  Code  0  ID  2/2 

Code  (Standard  State/Province)  as  defined  by  appropriate  government  agency. 

N403 

116 

Postal  Code  0  ID  3/9 

Code  defining  international  postal  zone  code  excluding  punctuation  and  blanks 
(zip  code  for  United  States). 

N404 

26 

Country  Code 

Code  identifying  the  country. 

0 

ID  2/3 

N405 

309 

Location  Qualifier 

Code  identifying  type  of  location. 

C 

ID  1/2 

N406 

310 

Location  Identifier 

C 

AN  1/25 

Code  which  identifies  a  specific  location. 
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DEPARTMENT  OP  DEFENSE 
DRAFT  UIPLEMENTATION  CONVENTION 


ANSI  ASC  X12  VERSION/RELEASE  00303000D 


Optional 


Segment:  PER  Administrative  Communications  Contact 
Levei:  Header 
Loop:  SPI/N1 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  identify  a  person  or  office  to  whom  administrative  communications 
should  be  directed 

Syntax:  1.  P0304  —  If  either  PER03  or  PER04  is  present,  then  the  other  is 
required. 

2.  P0506  —  If  either  PER05  or  PER06  is  present,  then  the  other  is 
required. 

Data  Element  Summa 


Mandatory 


Optional 


Conditional 


Conditional 


Conditional 


Conditional 


PER01  366  Contact  Function  Coda  M  ID  2/2 

Code  identifying  the  major  duty  or  responsibility  of  the  person  or  group  named. 

1C  Information  Contact 
Code  Value  Implementation  Note: 

Use  Code  1C  for  the  information  contact  within  the  originator's  organization. 


PER02  93  Name 

Free-form  name. 

Implementation  Note: 

Use  to  provide  the  name  of  the  irformation  point  of  contact. 

PER03  365  Communication  Number  Qualifier 

Code  identifying  the  type  of  communication  number. 

Implementation  Note: 

Use  any  appropriate  code  although  Code  EM  is  preferred. 

EM  Electronic  Mail 
FX  Facsimile 
TE  Telephone 
TM  Telemail 


O  AN  1/35 


C  ID  2/2 


PER04  364  Communication  Number  C  AN 

Complete  communicatbns  number  including  country  or  area  code  when 
applicable. 


C  AN  1/25 


PER05  365  Communication  Number  Qualifier 

Code  identifying  the  type  of  communicatron  number. 


C  ID  2/2 


PER06  364  Communication  Number  C  AN  1/25 

Complete  communications  number  including  country  or  area  code  when 
applicable. 
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841 • REFERENCE 
HL  ’  HIERARCHICAL  LEVEL 


Segment:  HL  Hierarchical  Level 


Mandatory 


Level:  Detail 
Loop:  HL  Repeat:  >i 
Usage:  Mandatory 
Max  Use:  1 

Purpose:  To  identify  dependencies  among  and  the  content  of  hierarchically  related 
groups  of  data  segments. 

Comments:  1.  The  HL  Segment  is  used  to  identify  levels  of  detail  information  using  a 
Hierarchical  Structure,  such  as  relating  line  item  data  to  shipment  data, 
and  packaging  data  to  line  item  data. 

2.  The  HL  segment  defines  a  top-down/left-right  ordered  structure. 

3.  HL01  shall  contain  a  unique  alphanumeric  number  for  each 
occurrence  of  the  HL  segment  in  the  transaction  set.  For  example  HL01 
could  be  used  to  indicate  the  number  of  occurrences  of  the  HL  segment, 
in  which  case  the  value  of  HL01  would  be  "I"  for  the  initial  HL  segment, 
and  would  be  incremented  by  one  in  each  subsequent  HL  segment 
within  the  transaction. 

4.  HL02  identifies  the  Hierarchical  ID  Number  of  the  HL  segment  to 
which  the  current  HL  segment  is  subordinate. 

5.  HL03  indicates  the  context  of  the  series  of  segments  following  the 
current  HL  segment  up  to  the  next  occurrence  of  an  HL  segment  in  the 
transaction.  For  example,  HL03  is  used  to  indicate  that  subsequent 
segments  in  the  HL  loop  form  a  logical  grouping  of  data  referring  to 
shipment,  order  or  item  level  information. 

6.  HL04  indicates  whether  or  not  there  are  subordinate  (or  child)  HL 
segments  related  to  the  current  HL  segment. 

Implementation  Notes: 

/.  The  HL  loop  can  be  used  to  reference  a  single  specificaiionJUem  of  technical  information,  e.g., 
an  Engineering  Data  List,  or  multiple  items  that  may  or  may  rwt  have  a  hierarchical  relationship. 

2.  When  referencing  a  single  specification  or  item  of  technical  information,  e.g.,  an  Engineering 
Data  List,  only  one  iteration  of  the  HL  loop  is  necessary. 

3.  When  referencing  multiple  items  that  may  or  may  not  have  a  hierarchical  relationship,  repeat 
the  HL  loop  as  many  times  as  required  to  specify  all  levels  and  use  as  many  iterations  of  the 
HUSPI  loop  as  necessary. 

4.  When  SPI07  is  Code  01 ,  the  only  entries  in  the  Detail  level  (Table  2 }  are  in  HUH  and  HU)3 . 


Data  Element  Summa 


DATA 

ELCMENT  NAME 


Mandatory 


Hierarchical  ID  Number  M  AN  1/12 

A  unique  number  assigned  by  the  sender  to  identify  a  particular  data  segment  in 
a  hierarchical  structure. 


DC20  •  JULY  9  1993 


16 


DEPART1IBIT  OF  ODENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


841  *  REFERENCE 

HL  •  HIERARCHICAL  LEVEL  ANSI  ASC  X12  VERSION/RELEASE  003030DOD. 


Optional 


Mandatory 


Implementation  Note: 

This  is  a  unique  and  progressive  number  assigned  by  the  originator  of  the  transaction  set  starting  with  the 
ruunber  ] , 

HL02  734  Hiararchical  Parant  ID  Number  O  AN  1/12 

Identification  number  of  the  next  higher  hierarchical  data  segment  that  the  data 
segment  being  described  is  subordinate  to. 

Implementation  Note: 

This  data  element  is  used  only  when  referencing  multiple  specifications  or  items  of  technical  information  that 
have  a  hierarchical  relationship. 

HL03  735  Hierarchical  Level  Code  M  ID  1/2 

Code  defining  the  characteristic  of  a  level  in  a  hierarchical  structure. 

Implementation  Note: 

Use  any  appropriate  listed  code  to  indicate  the  hierarchical  relationship  of  the  data. 

A  Assembly 
F  Component 
I  Item 

Code  Value  Implementatmn  Note: 

Use  Code  I  as  the  default  code  when  no  other  code  is  applicable. 

SY  System 
U  Subassembly 
ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  ZZ  only  when  SP107  is  Code  01.  This  is  required  to  comply  with  the  numdaiory  nature  of 
this  data  element. 


Optional 


HL04  736  Hierarchical  Child  Code  O  ID  1/1 

Code  indicating  whether  if  there  are  hierarchical  child  data  segments  subordinate 
to  the  level  being  described. 

Implementation  Note: 

When  referencing  single  or  multiple  specifications! technical  information  that  have  no  hierarchical 
relationship,  no  entry  is  required. 

0  No  Subordinate  HL  Segment  in  This  Hierarchical  Structure. 

Code  Value  Implementation  Note: 

Use  Code  0  to  indicate  the  lowest  level  of  the  hierarchical  relationship. 

1  Additional  Subordinate  HL  Data  Segment  in  This  Hierarchical  Structure. 

Code  Value  Implementation  Note: 

Use  Code  J  to  indicate  there  are  tower  level  items  in  this  hierarchical  relationshio. 


DEPARTMENT  OF  DEFENSE 

DRAFT  IMPLEMENTATION  CONVENTION 

841 • REFERENCE 

ANSI  ASC  X12  VERSION/RELEASE  003030DO0_  SPI  •  SPEORCATION  IDENTIFIER 


Optional 


Segment:  SPI  Specification  identifier 
Level:  Detail 

Loop:  HL/SPI  Repeat:  >1 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  provide  a  description  of  the  included  specification  or  technical  data 
items. 


Mandatory 


Data  Element  Summai 


SPI01  786  Security  Level  Code  M  ID  2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 


Implementation  Notes: 

1.  Use  any  code. 

2.  If  the  data  item  being  referenced  has  both  a  government  security  classification  and  a  commercial  security 
protection  requirement,  then  this  data  element  will  carry  the  government's  security  classification  code  and 
the  commercial  security  protection  code  will  be  carried  in  SPI09. 

3.  If  the  data  item  being  referenced  has  only  one  protection  requiremeru,  then  this  data  item  can  carry  either 
the  government  security  classification  or  the  commercial  security  protection  code. 


Mandatory 


SPI02  128  Reference  Number  Qualifier  M  ID  2/2 

Code  qualifying  the  Reference  Number. 

Implementation  Note: 

Any  code  may  be  used  but  typically  used  codes  include: 

DD  Document  Identification  Code 
Code  Value  Implementation  Note: 

Use  Code  DD  for  the  reference  number  of  an  Engineering  Data  List. 

DG  Drawing  Number 

QC  Product  Specification  Document  Number 

51  Engineering  Specification  Number 

52  Military  Specification  Number  (MILSPEC) 

53  Specification  Number 

TP  Test  Specification  Number 
W9  Special  Packaging  Instruction  Number 
ZZ  Mutually  Defined 
Code  Value  Implementation  Note: 

Use  Code  72.  for  another  type  of  reference  number  and  identify  that  number  in  SPI04. 


Mandatory  SPI03  127  Reference  Number  M  AN  1/30 

Reference  number  or  identification  number  as  defined  for  a  particular 
Transaction  Set,  or  as  specified  by  the  Reference  Number  Qualifier. 

Optional  SPI04  790  Entity  Title  O  AN  1/132 

Title  of  the  data  entity. 
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SPI  •  SPECIFICATION  IDENTIFIER  ANSI  ASC  X12  VERSION/RELEASE  003030DOD. 


Not  Used 
Optionsl 


Not  Used 
Not  Used 
Optionsl 


Not  Used 
Not  Used 
Not  Used 


Impl0m0ntatk)n  Note: 

When  SP102  is  Code  ZZ.  identify  the  reference  number  cited  in  SP103. 

SPI05  791  Entity  Purpose  O  AN  1/80 

SPI06  792  Entity  Ststus  Code  O  10  1/1 

Code  indicating  the  current  status  of  the  data  item  specified  by  the  electronic 
data  item. 

Implementation  Note: 

Use  any  code. 

Z  Mutually  Defined 

Code  Value  Implementation  Note: 

Use  Code  Z for  another  entity  status  code  and  explain  in  the  MSG  segment. 


SPI07 

353 

Transaction  Sat  Purpose  Code 

O 

ID 

2/2 

SPi08 

755 

Report  Type  Coda 

0 

ID 

2/2 

SPt09 

786 

Security  Level  Code 

0 

ID 

2/2 

Code  indicating  the  level  of  confidentiality  assigned  by  the  sender  to  the 
information  following. 


Implementation  Note: 

Use  this  data  element  ONLY  when  SPIOJ  is  Code  96. 92,  93,  94,  or  99,  and  the  data  item  being  referenced 
also  has  a  commercial  security  protection  requirement. 

00  Company  Non-Classified 
01  Company  Internal  Use  Only 
02  Company  Confidential 

03  Company  Confidential,  Restricted  (Need  to  Know) 

04  Company  Registered  (Signature  Required) 

05  Personal 

09  Company  Defined  (Trading  Partner  Level) 


SPI10 

559 

Agency  Qualifier  Code 

O 

ID 

2/2 

SPI11 

916 

Code  List  Reference 

O 

AN 

1/6 

SPI12 

554 

Assigned  Number 

O 

NO 

1/6 
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ROT  •  REVISION  DATEAIME 


Optional 


Segment:  RDT  Revision  Date/Time 


Levei:  Detail 
Loop:  HUSPI 
Usage:  Optional 
Max  Use:  >1 

Puipose:  To  specify  the  revision  level  of  the  electronic  data  item. 

Syntax:  1.  C0102  —  If  RDT01  is  present,  then  RDT02  is  required. 

2.  L030405  —  If  RDT03  is  present,  then  at  least  one  of  RDT04  or 
RDT05  are  required. 

3.  00605  —  If  RDT06  is  present,  then  RDT05  is  required. 
Implementation  Note: 

Vse  this  segment  to  specify  the  revision,  change,  or  version  of  the  specificationJ  technical 
inf  Or,  <iation  being  referenced. 

Data  Element  Summa 


Optional 


Conditional 


Optional 


Conditional 


Not  Usad 
Not  Usad 


RDT01  795  Revision  Level  Code  O  ID  1/1 

Code  indicating  the  revision  or  engineering  change  level  of  the  data  items 
referred  to  by  the  specification  number. 

A  Change  Level 
E  Revision  Level 
H  Version  Level 

RDT02  796  Revision  Value  C  AN  1/30 

Revision  or  engineering  change  level  of  the  data  items  referred  to  by  the 
specification  number. 

Implementation  Notes: 

1.  When  RDTOl  is  Code  A  or  E,  indicate  the  change  or  revision  number/ letter. 

2.  When  RDTOl  is  Code  H,  specify  the  version  of  the  data  item,  e.g.,  "As-Built"  or  "As-Shipped." 

RDT03  374  Oate/Time  Qualifier  O  ID  3/3 

Code  specifying  type  of  date  or  time,  or  both  date  and  time. 

007  Effective 

Code  Value  Implementation  Note: 

Use  Code  007  to  indicate  the  change,  revision,  or  version  date. 


RDT04  373  Date 

Date  (YYMMDD). 

Implementation  Note: 

Enter  the  date  of  the  change,  revision,  or  version. 

RDT05  337  Time 

RDT06  623  Time  Code 


C  DT 


C  TM 
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UN  •  ITEM  IDENTIFICATION  ANSI  ASC  X12  VERSION/RELEASE  003030DOD. 


Optional 


Not  Used 
Mandatory 


Segment:  LIN  Item  Identification 
Level:  Detail 
Loop:  HUSPI 
Usage:  Optional 
Max  Use:  1 

Purpose:  To  specify  basic  item  identification  data. 

Syntax:  1.  C0405  —  If  LIN04  is  present,  then  LINOS  is  required. 

2.  C0607  —  If  LIN06  is  present,  then  LIN07  is  required. 

3.  C0809  —  If  L1N08  is  present,  then  LIN09  is  required 

4.  C101 1  —  If  LIN10  is  present,  then  LIN1 1  is  required. 

5.  C1213  —  If  LIN12  IS  present,  then  LIN13  is  required. 

6.  C141 5  —  If  LIN14  is  present,  then  LIN1 5  is  required. 

7.  C1617  —  If  LIN16  is  present,  then  LIN17  is  required. 

8.  Cl 81 9  —  If  LIN18  is  present,  then  LIN19  is  required. 

9.  C2021  —  If  LIN20  is  present,  then  LIN21  is  requifed. 

10.  C2223  —  If  LIN22  is  present,  then  LIN23  is  required. 

11.  C2425  —  If  LIN24  is  present,  then  LIN25  is  required. 

12.  C2627  —  If  LIN26  is  present,  then  LIN27  is  required. 

13.  C2829  —  If  LIN28  is  present,  then  LIN29  is  required. 

14.  C3031  —  If  LIN30  is  present,  then  LIN31  is  required. 

Semantic:  LIN01  is  the  line  item  identification 

Comments:  1.  See  the  Data  Dictionary  for  a  complete  list  of  ID  s. 

2.  LIN02  through  LIN31  provide  for  fifteen  (15)  different  proouct/service 
ID’S  for  each  item.  For  Example;  Case,  Color,  Drawing  No.,  UPC  No., 
ISBN  No  ,  Model  No.,  SKU. 

Implementation  Notes: 

1.  Use  this  segment  to  transmit  information  relative  to  the  data  item  ideruifieii  in  SPI03,  e.g., 
national  stock  number  (NSN),  part  number,  item  description,  etc. 

2.  LIN02  through  LINS  1  are  used  in  pairs  (i.e.,  LJN02  and  LINOS)  as  required  to  carry  additional 
information  about  the  specific  data  item  identified  in  SPIOS. 


Data  Element  Summary 

RfcF. 

DCS. 

DATA 

ELCMCMT 

NAME 

ATTR»l/rES 

LINOI 

350 

Assigned  Identificatton  0 

AN  1/11 

LIN02 

235 

Product/Service  ID  Qualifier  M 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID  2/2 

i 

F7  End-Item  Description 
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Mandatory 

Optional 

Conditional 

Optional 

Conditional 

Optional 

Conditional 

Optional 

Conditional 

Optional 


Code  Value  Implementation  Note: 

Use  Code  F7  for  the  application  reference  from  an  Engineering  Data  List. 

FS  National  Stock  Number 
Code  Value  Implementation  Note: 

Use  Code  FS  for  the  National  Stock  Number. 

IN  Buyer's  item  Number 

Code  Value  Implementation  Note: 

Use  Code  IN  for  the  CLIN  or  SUBCUN 

MG  Manufacturer's  Part  Number 
Code  Value  Implementation  Note: 

Use  Code  MG  for  a  manufacturer's  part  number. 

PD  Part  Number  Description 

Code  Value  Implementation  Note: 

Use  Code  PD  for  a  noun  description  from  an  Engineering  Data  List. 

ZZ  Mutually  Defined 

Code  Value  Implementation  Note: 

Use  Code  ZZ  for  the  Data  Tech  organization. 

LINOS  234  Product/Service  ID  M  AN  1/30 

Identifying  number  for  a  product  or  service. 

LIN04  235  Product/Service  ID  Qualifier  O  ID  2)2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

LINOS  234  Product/Service  ID  C  AN  1/30 

Identifying  number  for  a  product  or  service. 

LIN06  235  Product/Service  ID  Qualifier  O  ID  2/2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

LINO?  234  Product/Service  ID  C  AN  1/30 

Identifying  number  for  a  product  or  service. 

LINOS  235  Product/Service  ID  Qualifier  O  ID  2/2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

LIN09  234  Product/Service  ID  C  AN  1/30 

Identifying  number  for  a  product  or  service. 

LINIO  235  Product/Service  ID  Qualifier  O  ID  2/2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

LIN11  234  Product/Service  ID  C  AN  1/30 

Identifying  number  for  a  product  or  service. 

LIN12  235  Product/Service  ID  Qualifier  O  ID  2/2 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 


Conditional 


LIN 13  234  Product/Service  ID 


C  AN  1/30 
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Identifying  number  for  a  product  or  service. 

Optional 

LIN14 

235 

Product/Service  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN15 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  serv  ice. 

AN 

1/30 

Optional 

LIN16 

235 

Product/Servica  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN17 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN18 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LINT  9 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN20 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Ptoduct/Service  ID  (^4). 

ID 

2/2 

Conditional 

LIN21 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN22 

235 

Product/Service  ID  Qualifier  0 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN23 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

L(N24 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN25 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN26 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (^4). 

ID 

2/2 

Conditional 

LIN27 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 

Optional 

LIN28 

235 

Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 

ID 

2/2 

Conditional 

LIN29 

234 

Product/Service  ID  C 

Identifying  number  for  a  product  or  service. 

AN 

1/30 
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Optional 


Conditional 


LIN30  235 


LIN31  234 


Product/Service  ID  Qualifier  O 

Code  identifying  the  type/source  of  the  descriptive  number  used  in 
Product/Service  ID  (234). 


ID 


2/2 


Product/Service  ID 

Identifying  number  for  a  product  or  service. 


C  AN  1/30 
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Optional 


Segment:  N1  Name 
Level:  Detail 
Loop:  HL/SPI 
Usage:  Optional 
Max  Use:  >1 

Purpose:  To  identify  a  party  by  type  of  organization,  name  and  code 

Syntax:  1.  R0203  —  At  least  one  of  N1 02  or  N1 03  is  required. 

2.  P0304  —  If  either  N1 03  or  N104  is  present,  then  the  other  is  required. 

Comment:  This  segment,  used  alone,  provides  the  most  efficient  method  of 

providing  organizational  identification.  To  obtain  this  efficiency  the  "ID 
Code"  (N104)  must  provide  a  key  to  the  table  maintained  by  the 
transaction  processing  party. 


Mandatory 


Conditional 


Conditional 


Conditional 


_ Data  Element  Summary _ 

IICF.  DATA 

OtS.  ILiMIKT  MAMK  ATTWW/TtS 

N101  98  Entity  Idantifier  Code  M  ID  2/2 

Code  identifying  an  organizational  entity,  a  physical  location,  or  an  individual 

33  Inquiry  Address 
Code  Value  Implementation  Note: 

Use  Code  33  to  identify  a  Data  Tech  entity  from  an  Engineering  Data  List. 

ZE  End  Item  Manufacturer 
Code  Value  Implementation  Note: 

Use  Code  ZE  to  identify  the  manufacturer  from  an  Engineering  Data  List. 


N102 

93 

Name 

Free-form  name. 

C 

AN 

1/35 

N103 

66 

Identification  Code  Qualifier 

C 

ID 

1/2 

Code  designating  the  system/method  of  code  structure  used  for  Identification 
Code  (67). 

10  Department  of  Defense  Activity  Address  Code  (DODAAC) 

33  Commercial  and  Government  Entity  (CAGE) 

N104  67  identification  Code  C  AN  2/17 

Code  identifying  a  party  or  other  code. 
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Optional 


Mandatory 

Not  Uaad 


Segment:  MSG  Message  Text 
Level:  Detail 
Loop:  HL/SPI 
Usage:  Optional 
Max  Use:  >1 


Purpose:  To  provide  a  free  form  format  that  would  allow  the  transmission  of  text 
information. 

Comment:  MSG02  is  not  related  to  the  specific  characteristics  of  a  printer,  but 
identifies  top  of  page,  advance  a  line,  etc. 

Implemantation  Notes: 

1.  Use  ihis  segment  to  provide  information  relative  to  a  specific  data  item. 

2.  Maximum  use  is  3 . 


Data  Element  Summary 


RIP. 

DCS. 

DATA 

ELlMOn 

NAME 

ATnWtfTES 

MSG01 

933 

Free-Form  Meuaga  Text 

Free-form  message  text. 

M 

AN 

1/264 

MSG02 

934 

Printer  Carriage  Control  Code 

0 

ID 

2/2 
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SE  •  TRANSACTION  SET  TRAILER  ANSI  ASC  X12  VERSION/RELEASE  003030000. 


Mandatory 


Mandatory 


Mandatory 


Segment:  SE  Transaction  Set  Trailer 
Level:  Summary 

Loop:  _ 

Usage:  Mandatory 
Max  Use:  1 

Purpose:  To  indicate  the  end  of  the  transaction  set  and  provide  the  count  of  the 
transmitted  segments  (including  the  beginning  (ST)  and  ending  (SE) 
segments). 

Comment:  SE  is  the  last  segment  of  each  transaction  set. 


Data  Element  Summai 


ATTIiaUTCS 


SE01  96  Number  of  Included  Segments  M  NO  1/10 

Total  number  of  segments  included  in  a  transaction  set  including  ST  and  SE 
segments. 


SE02  329  Transaction  Set  Control  Number  M  AN  4/9 

Identifying  control  number  that  must  be  unique  within  the  transaction  set 
functional  group  assigned  by  the  originator  for  a  transaction  set 

Implementation  Note: 

Enter  the  same  number  as  carried  in  STOI. 
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In  this  chapter,  applicable  ASC  X12  forms  are  presented. 


4.0^ 


BASEUNE  AS  OF:  JULY  9, 1993 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


Rw.  9/14/Sa 

ASC  X12  WORK  REQUEST  FORM 
SUBMITTER  INSTRUCTIONS 


NOTE:  ALL  REQUESTS  MUST  BE  TYPED  OR  PRINTED  LEGIBLY  IN  BLACK  INK. 
INCOMPLETE  OR  ILLEGIBLE  WORK  REQUESTS  WILL  BE  RETURNED  TO  THE 
SUBMITTER. 

Submit  completed  forms  to:  Technical  Department.  ASC  Xi2  Secretariat  Data  Interchange  Standards  Association, 
Inc..  1800  Diagonal  Road.  Suite  355.  Alexandria.  VA  22314-2852  or  FAX  (703)  548-5738.  Submitters  are  nocMed  of 
the  status  of  the  work  request  after  it  has  been  reviewed  by  X12J  Technical  Assessment  Subcommittee. 

1.  TO  USE  THIS  FORM  TO  REQUEST  A  CHANGE  TO  AN  EXISTING  STANDARO(S),  use  ONE  Work  Request 
(WR)  Form  to  list  att  changes  needed  to  meet  one  BUSINESS  REASON.  Otherwise  use  multiple  forme.  If  more 
space  is  necessary,  numbered  attachments  may  be  used  for  corrtlnuatloa 

2.  TO  USE  THIS  FORM  FOR  SUPPORTING  DATA  MAINTENANCE  FOR  A  NEW  DRAFT  STANDARD,  list  al 
information  on  ONE  form;  use  anachments  as  necessary.  List  first  al  new  segments,  thert  al  now  data 
elements/codes/code  sources.  Then  list  revisions  to  existing  segments  and  data  aiements/codee/code  aourcae; 
provide  a  busirtess  case  for  revislorts  to  existirtg  startdards.  Then  list  any  others  changes  rteeded  (e.g.,  X12.5. 
X12.6).  including  Justification. 

3.  TO  USE  THIS  FORM  TO  REQUEST  A  PROPOSED  NEW  X12  STANDARDS  PROJECT,  provide  the  busineee 
need  and  Justification  for  the  new  project  in  Part  0.  TheWRwllberefatTadtoanXl2tubcommlteeforanalysia. 

ADDITIONAL  INFORMATION  FOR  COMPLETING  THIS  FORM: 

PART  A:  SUBMITTER  INFORMATION:  The  WR  may  represent  the  position  of  an  Individual,  mdusby  group,  work 
group.  XI 2  subgroup,  etc  if  the  WR  represents  the  position  of  an  XI 2  aubconmttee-raiatad  work  group,  the 
subcommittee  chair  must  initial  the  WR. 

PART  B:  REFERENCE  USED:  Indicate  the  vorsion/reioase  or  odUon  of  the  standard  you  are  using  as  a  rafaranoe. 

PART  C:  RAMinCATIONS:  List  affactad  transaction  sets,  segtnonts  and  data  alomants.  or  other  standards.  Fora 
control  standard,  name  the  affected  page  and  section  number. 

PART  D:  BUSINESS  CASE/REASON  FOR  CHANGE:  Provide  a  compisia  scenario  that  describes  the  business 
function/operation  that  w«  be  satisfied  by  a  change  to  the  standard.  Be  spedHc.  because  this  MonnationwB 
appear  In  the  XI 2  membership  ballot  pa^ge  and  w«  be  the  only  infOnnaiion  that  members  have  on  which  to  base 
theirvote.  X1 2J  Technical  Assessment  Subcommittee  requiras  enough  Monnation  to  be  able  to  propose  an 
alternate  solution  to  the  one  provided,  if  necessary. 

PART  E:  PROPOSED  WORK:  List  the  specific  changes  being  requested.  Give  the  names  and  asaodatad 
identifiers  of  the  standards  segments,  dausiemems  and  codes  affactad  by  the  changes.  OelInMona  for  naw  codes 
and  for  industry-specific  terms  must  be  complete.  For  new  codes,  provide  a  proposed  code  and  a  code  delMdoa 
RULES:  (1)  Acronyms/abbrevlations  cannot  be  added  to  the  stanctarde-they  must  be  spaledouL  ^)Piovldean 
expanded  code  definition  for  each  code  that  Is  not  compieteiy  seif  explanatory,  that  Is.  farms  thtf  are  not  in  general 
business  use  or  that  are  Industry  spedflc.  (3)  Provide  code  source  rsforancae  for  al  a)domaly  publlshad  (non-Xl2) 
code  lists  dtad  (use  the  Form  for  New  or  Revised  Code  Source  Rsfaranca.  page  2  of  the  fom^. 
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Oats  Submittad  NUMB6S 

(SubniiRar  Provida)  _  (Sacrauflat  Only) 

ASC  X12 

WORK  REQUEST  FORM 

A.  SUBMITTER  INFORMATION: 

Subminar  Nama _ _  Company _ _ 

Addrass  _ Addrasa/21P  _ /ZIP  *4 _ 

Phona 

Submission  raprasants  tha  position  oh _ SC  Chair  Initials:  _ 


B.  REFERENCE  USED:  Varsion  /Ralaasa _ /Sufaralaasa  or  Workbook  (data) 


C.  RAMIFICATIONS: 

Transaction  Sat(9)  Usad 
Sagmant(9)  Affactad 
Data  Bamam(s)  Affactad 
Othar  Standard(s) 


D.  BUSINESS  CASE/REASON  FOR  CHANGE: 


E.  PROPOSED  WORK: 
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5.0  GLOSSARY 


This  chapter  cootains  ASC  XI 2-  and  DoD-specific  glossaries. 

5.1  X12  GLOSSARY 

ANSI 

American  National  Standards  Institute 
ANSI  Standard 

A  document  published  by  ANSI  that  has  been  ^proved  through 
the  consensus  process  of  public  announcement  and  review.  Each 
such  standards  must  have  been  developed  by  an  ANSI  committee 
and  must  be  revisited  by  that  committee  within  S  years  for  updat¬ 
ing.  See  Draft  Standard  for  Trial  Use  (DSTU). 

Area  Transaction  Set 

A  predefined  area  within  a  transaction  set  (header,  detail,  sum¬ 
mary)  containing  segments  and  their  various  attributes. 

ASC  X12 

Accredited  Standards  Committee,  X12.  It  conqirises  industry 
members  who  create  electronic  data  interchange  (EDI)  standards 
for  submission  to  ANSI  for  subsequent  apivoval  and  dissemination. 

Anthentication 

A  mechanism  that  allows  the  receiver  of  an  electronic  transmission 
to  verify  the  sender  and  the  integrity  of  the  content  of  the  trans¬ 
mission  through  the  use  of  an  electronic  “key”  or  algorithm  shared 
by  the  trading  partners.  That  algorithm  is  sometimes  referred  to 
as  an  electronic  signamte. 

Compliance  Checking 

A  checking  process  that  is  used  to  ensure  that  a  transmission 
complies  with  ANSI  X12  syntax  rules. 

Conditiotui  (C) 

A  data  element  requirement  designator  that  indicates  that  the 
presence  of  a  specified  data  element  is  dependent  on  the  value  or 
presence  of  other  data  elements  in  the  segment.  The  condition 
must  be  stated  and  must  be  computer  processable. 

Control  Segment 

A  segment  that  has  the  same  structure  as  a  data  segment  but  is 
used  for  transferring  control  information  for  grouping  data  seg¬ 
ments.  Control  segments  may  be  loop  control  segments  (LS/LE), 
transaction  set  control  segments  (ST/SE),  or  functional  group  con¬ 
trol  segments  (GS/GE),  defined  in  XI  2.6,  or  interchange  control 
segments  (ISA/IEA/TAl)  defined  in  X12.S. 
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Data  Element 

The  basic  unit  of  information  in  the  EDI  standards  containing  a 
set  of  values  that  represent  a  singular  fact.  It  may  be  single-char¬ 
acter  codes,  literal  descriptions,  or  numeric  values. 

Data  Element  Length 

The  range,  minimum  to  maximum,  of  the  number  of  character 
positions  available  to  represent  the  value  of  a  data  element.  A 
data  element  may  be  of  variable  length  and  range  from  minimum 
to  maximum  or  it  may  be  of  fixed  length  in  which  the  minimum 
is  equal  to  the  maximum. 

Data  Element  Reference  Number 

Number  assigned  to  each  dau  element  as  a  unique  identifier. 
Data  Element  Requirement  Designator 

A  code  defining  the  need  for  a  data  element  value  to  ^pear  in  the 
segment  if  the  segment  is  transmitted.  The  XI 2  codes  are  man¬ 
datory  (M),  optional  (O),  or  conditional  (C).  DoD  may  consider 
a  segment  “mandatory”  even  through  it  is  “optional”  by  X12 
standards. 

Data  Element  Separator 

A  unique  character  preceding  each  data  element  that  is  used  to 
delimit  data  elements  within  a  segment  DoD  uses  as  the 
delimiter. 

Data  Element  Type 

A  data  element  may  be  one  of  six  types;  numeric,  decimal, 
identifier,  string,  date,  or  time. 

Delimiters 

Two  levels  of  separators  and  a  terminator.  The  delimiters  are  an 
integral  part  of  the  transferred  data  streant  They  are  specified  in 
the  interchange  header  and  may  not  be  used  in  a  data  element 
value  elsewhere  in  the  interchange.  From  highest  to  lowest  level, 
the  separators  and  terminator  are  segment  terminator  and  data 
element  separator. 

DISA 

Data  Interchange  Standards  Association.  A  nonprofit  organization 
funded  by  ASC  X12  members  to  serve  as  the  Secretariat  for  X12. 

DSTU 

Draft  Standwi  for  Trial  Use.  It  represents  a  document  approved 
for  publication  by  the  full  X12  committee  following  membership 
consensus  and  subsequent  resolution  of  negative  votes.  (Final 
Report  of  X12  Publications  Task  Group).  The  Draft  EDI  Standard 
for  Trial  Use  document  represents  an  ASC  X12  approved  standard 
for  use  prior  to  approval  by  ANSI.  See  ANSI  Standard. 


2 


BASELINE  AS  OF:  JULY  9,1993 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 


EDI 

Electronic  data  interchange.  The  compuier-application-to-com- 
puter- application  exchange  of  business  information  in  a  standard  •' 
format. 

Electronic  Envelope 

Electronic  informauon  that  binds  together  a  set  of  transmitted 
documents  being  sent  from  one  sendei  to  one  receiver. 

Element  Delimiter 

A  single-character  that  follows  the  segment  identifier  and  separates 
each  data  element  in  a  segment  except  the  last. 

Functional  Group 

A  group  of  one  or  more  transaction  sets  bounded  by  a  functional 
group  header  segment  and  a  functional  group  trailer  segment. 

Functional  Group  Segments  (GS/GE) 

These  segments  identify  a  specific  functional  group  of  documents 
such  as  purchase  orders. 

Industry  Conventions 

Defines  how  the  ASC  X12  standards  are  used  by  the  specific 
industry 

Industry  Guidelines 

Defines  the  EDI  environment  for  using  conventions  within  an 
industry.  It  provides  assistance  on  how  to  inqilement  X12  stand¬ 
ards. 

Interchange  Control  Segments  (ISA/IEA) 

These  segments  identify  a  unique  interciiange  being  sert  from  one 
sender  to  one  receiver  (see  electronic  envelope). 

Interchange  Control  Stmctnre 

The  interchange  header  and  trailer  segments  that  envelop  one  or 
more  functional  groups  or  interchange-related  control  segments  and 
perform  the  following  functions;  (1)  defines  the  data  element 
separators  and  the  data  segment  terminators,  (2)  identifies  the 
sender  and  receiver,  (3)  provides  control  information  for  the  inter¬ 
change,  and  (4)  allows  for  authorization  and  security  information. 
(X12.5) 

Loop 

A  group  of  semantically  related  segments;  these  segments  may  be 
either  bounded  or  unbounded  (X12.6).  The  N1  loop  is  an  example 
of  a  loop,  which  includes  Segments  N1  to  PER  for  name  and 
address  information. 

Mandatory  (M) 

A  data  element/segment  requirement  designator  that  indicates  the 
presence  of  a  specified  data  element  is  required. 
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Mapping 

The  process  of  identifying  the  standard  data  element’s  relationship 
to  application  data  elements. 

Max  Use 

Specifies  the  maximum  number  of  times  a  segment  can  be  used  at 
the  location  in  a  transaction  set 

Message 

Entire  data  stream  including  the  outer  envelope 
Optional  (O) 

A  data  element/segment  requirement  designator  that  indicates  the 
presence  of  •>  specified  data  element/segment  is  at  the  option  of 
the  sending  party  and  can  be  based  on  the  mutual  agreement  of 
the  interchange  parties. 

Qualifier 

A  data  element  that  identifies  or  defines  a  related  element,  set  of 
elements,  or  a  segment.  The  qualifier  contains  a  code  taken  from 
a  list  of  approved  codes. 

Repeating  Segment 

A  segment  that  may  be  used  more  than  once  at  a  given  location 
in  a  transaction  set.  See  Max  Use. 

Security 

System  screening  that  denies  access  to  unauthorized  users  and 
protects  data  from  unauthorized  uses 

Segment 

Segments  consist  of  logically  related  data  elements  in  a  defined 
sequence.  A  data  segment  consists  of  a  segment  identifier,  one  or 
more  data  elements  each  preceded  by  an  element  separator,  and 
a  segment  terminator. 

Segment  Directory 

Provides  the  purpose  and  format  of  the  segments  used  in  the 
construction  of  transaction  sets.  The  directory  lists  each  segment 
by  name,  purpose,  identifier,  the  contained  data  elements  in  the 
specified  order,  and  the  requirement  designator  for  each  data 
element. 

Segment  Identifier 

A  unique  identifier  for  a  j?gment,  consisting  of  a  combination  of 
two  or  three  upper-case  letters  and  digits.  The  segment  identifier 
occupies  the  first-character  positions  of  the  segment.  It  is  not  a 
data  element.  The  segment  identifier  in  EDIFACT  is  a  component 
data  element  —  part  of  a  composite  data  element  consisting  of  a 
segment  identifier  and  an  explicit  looping  designator. 


5.0.4 


BASEUNE  AS  OF:  JULY  9,1993 


DEPARTMENT  OF  DEFENSE 
DRAFT  IMPLEMENTATION  CONVENTION 

Segment  Terminator 

A  unique  character  appearing  at  the  end  of  a  segment  to  indicate 
the  termination  of  the  segment,  e.g.,  N/L. 

Syntax 

The  grammar  or  rules  that  define  the  structure  of  the  EDI  standards 
(i.e.,  the  use  of  loops,  qualifiers,  etc.).  Syntax  rules  are  published 
in  ANSI  X12.6. 

Transaction  Set 

A  document  that  unambiguously  defines,  in  the  standard  syntax, 
information  of  business  or  strategic  significance  and  consists  of  a 
1  eader  segment,  one  or  more  data  segments  in  a  specified  order, 
<jid  a  trailer  segment. 

Transaction  Set  ID 

An  identifier  that  uniquely  identifies  the  transaction  set.  This 
identifier  is  the  first  dau  element  of  the  transaction  set  header 
segment. 

Translation 

The  act  of  accepting  documents  in  other  than  standard  format  and 
translating  them  to  the  standard. 

Version/Release 

Identifies  the  publication  of  the  standard  being  used  for  the  genera¬ 
tion  or  the  interpretation  of  data  in  the  X12  standard  format.  May 
be  found  in  the  Functional  Group  Header  Segment  (GS)  and  in  the 
Interchange  Control  Header  Segment  (ISA).  See  Control  Segment. 

Vies  Committee 

Voluntary  Interindustry  Communications  Standards  for  EDI. 

X12 

The  ANSI  committee  responsible  for  the  development  and  main¬ 
tenance  of  standards  for  EDI. 

X12^ 

Interchange  Control  Structure.  This  standard  provides  the  inter¬ 
change  envelope  of  a  header  and  trailer  for  the  electronic  inter¬ 
change  through  a  data  transmission,  and  it  provides  a  stiuaure  to 
acknowledge  the  receipt  and  processing  of  this  envelope. 

X12.6 

Application  Control  Structure.  This  standard  describes  the  control 
segments  used  to  envelop  loops  of  data  segments,  transaction  sets, 
and  groups  of  related  transaction  sets. 
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AIS 

Automated  information  systems 
DUSD  (Logistics) 

Deputy  Under  Secretary  of  Defense  (Logistics) 

DES 

Data  encryption  standard 
DISA 

Defense  Information  Systems  Agency 
DLA 

Defense  Logistics  Agency 
ISA 

Interchange  control  header-  identifier 
NIST 

National  Institute  of  Standards  and  Technology 
NTE 

Note  identifier 
PLUS 

Protection  of  logistics  unclassified/sensitive  systems 
UN/EDIFACT 

EDIFACT;  electronic  data  interchange  for  administration,  com¬ 
merce,  and  transport 

USD  (A  &  T) 

Under  Secretary  of  Defense  for  Acquisition  and  Technology 
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